Software Vault: The Diamond Collection/The Diamond Collection (Software Vault)(Digital Impact).ISO/cdr16/tc15_047.zip/TC15-047.TXT

Text File | 1995-01-22 | 30KB | 737 lines

TELECOM Digest     Thu, 19 Jan 95 08:01:00 CST    Volume 15 : Issue 47

Inside This Issue:                          Editor: Patrick A. Townson

    CO/Boston Added to NACN (Doug Reuben)
    Canadian CIC Codes: (Chris Farrar)
    Questions About WAN Compression For Data Networks (Peter Granic)
    Re: DQDB and SMDS (Kristoff Bonne)
    ANSI Terminal Communications (David O. Laney)
    Internet Software Wanted (L.C. Clower)
    Re: T1BBS Gone? (Mark Fraser)
    Re: BC Tel, SaskTel, Internet (Mark Fraser)
    Re: Wireless CO's Challenge New NPAs? (Liron Lightwood)
    Re: Attention: 800 Number Subscribers (News Alert) (Colum Mylod)
    Re: GSM Cellular Operators List (Ben Wright)
    Summary: Looking For a CHILL Compiler (Andreas Junklewitz)
    Re: NANP 800 Numbers From the UK (Carl Moore)
    Re: Legal Problem Due to Modified Radio (Alan Boritz)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and America
On Line. It is also gatewayed to Usenet where it appears as the
moderated
newsgroup 'comp.dcom.telecom'.

Subscriptions are available to qualified organizations and individual
readers. Write and tell us how you qualify:

                 * [e-mail] *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax
or phone at:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: [phone]
                        Fax: [phone]
  ** Article submission address only: [e-mail] **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

**********************************************************************
***
*   TELECOM Digest is partially funded by a grant from the
*
* International Telecommunication Union (ITU) in Geneva, Switzerland
*
* under the aegis of its Telecom Information Exchange Services (TIES)
*
* project.  Views expressed herein should not be construed as
represent-*
* ing views of the ITU.
*
**********************************************************************
***

Additionally, the Digest is funded by gifts from generous readers such
as yourself who provide funding in amounts deemed appropriate. Your
help
is important and appreciated. A suggested donation of twenty dollars
per
year per reader is considered appropriate. See our address above.

All opinions expressed herein are deemed to be those of the author.
Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------

From: [e-mail] (Doug Reuben)
Subject: CO/Boston Added to NACN
Date: Thu, 19 Jan 1995 03:37:13 EST


I just noticed that CO/Boston was added to the NACN today. Although a
bit late, it is a welcome improvement!

Prior to CO/Boston's (00007) addition to the NACN, there was a large
coverage "gap" for automatic call delivery from Rhode Island (which
Metro Mobile for some reason never hooked up with NY) all the way up
to southern New Hampshire. (Central/Northern Seacoast NH as well as
Vanguard Cellular in Maine were added last year.) CO/Boston also
"shares" a seemingly bizare system with Atlantic Cellular (CO/Vermont)
in the Lakes region of central New Hampshire, and it is possible that
on BOSTON-owned towers NACN customers will get automatic call delivery
there as well.

I tried my Boston account out, and all features work very nicely, even
to a limited extent redirects. In summary:

-Redirects: If your call is delivered to a visited NACN market from
Boston, redirects, or treatment of a call after no-answer to either
voicemail or some other no-answer-transfer number WILL work, although
to a very limited extent. Calls will NOT go back to voicemail, but
will no-answer-transfer (NAT) to other numbers.

 From only a few cursory tests, it looks like what they are doing is
allowing NAT to calls within the same local service area. That is, as
long as the call would NOT have to go over an IXC if it were placed by
the roamer in the visited market, then it will be allowed. Thus, for
example, a Boston customer who roams in CO/NY's (00025) system will
NOT be allowed to have redirects go back to his/her voicemail in
Boston, nor will redirects be allowed to a NAT# in Washington, DC.
However, NAT will be allowed to a number within the NY Metro LATA (but
not, it seems, the local "toll-free" area.)

Thus, if the NAT condition in effect for the Boston subscriber is
while the subscriber is visiting the CO/NY system is:

*71#555-1212 (the #555-1212 instructs the Boston switch to NAT to
voicemail, which is problematic at times, especially on other Motorola
switches linked to Boston [non-NACN]), the result is a "xx-20" switch
recording informing the caller that the roamer/visitor is unavailable,
generated by the visited (NY) switch.

*71-305-555-1212, OR *71-1-305-555-1212 results in an ERRONEOUS
"xx-44" recording, which is roughly "As a roamer, you must first dial
a 1 when calling this number. Please call 611 and reference message
[xx]-44."  Quite confusing to landline callers indeed!

*71-212-555-1212 or *71-800-555-1212: NAT works properly.

This seems to make sense: If the DOJ forbids SWBell/Boston to offer
redirects over an IXC (or from what I am told since SWBell is
potentially too lazy to get a waiver for VM purposes :( ), then as
long as the calls are NOT carried via an IXC, NAT can be offered
without a waiver.

The ANI from sample local redirects in the CO/NY system show a
516/Long Island number, and I suspect that these are coming from the
Woodbury Switch. Hence, as long as the calls can be processed by CO/NY
and/or do not cross LATA boundries (?), NAT will work.

Although it would be nice if NAT would work back to VM in Boston, the
ability to have some sort of local/800 redirect is a CERTAINLY better
than nothing.

-Call Forwarding: It's nice to see that Boston was not forced to
adhere to the McCaw feature codes, and that they are allowed to retain
their own codes for their own customers. *71 (NAT for Boston), *72
(Call Forwarding for Boston), *713 (NAT Cancel), *723 (CF Cancel), *73
(Global NAT/CF/Busy Transfer Cancel) all work fine, and receive a
prompt confirmation tone.

Moreover, CO/Boston customers who use NAT, *713, or *73 do NOT have to
lose voicemail as they do in Connecticut or other non-NACN markets
(I'm am no longer sure of CT's "non-NACN" status - they are doing
weird things with roaming from what I hear. I need to test a few
things out next time I am there to be sure...). If a CO/Boston
customer who roams on the NACN chooses to set NAT away from voicemail
to another destination (such as a "local" number as in the above
example), and subsequently wishes to re-establish NAT to VM in Boston,
entering *71#555-1212 WILL work, ie, it will set up the correct NAT
coding in the Boston switch.  Although as noted above a redirect will
not work back to Boston VM, if the subscriber chose to activate the Do
Not Disturb (*35) feature to turn off call delivery to the visited
market, an incoming call would be properly treated in Boston and sent
to voicemail.

The ability activate/deactivate voicemail remotely and establish
different NAT settings from anywhere within the NACN is a useful
feature, one which is seemingly not widely available on the B-side
auto call delivery network.

-Do Not Disturb: *350/*35 works perfectly. It's odd that Boston chose
to go with these codes, they use the more standard Motorola codes
*28/*29 for their auto call delivery in VT, Mass, and CT. Perhaps they
want to distinguish between the NACN and New England call delivery?
Why? Boston makes call-delivery difficult enough already with their
"call delivery home airtime sometimes" charges, why add an extra layer
of confusion?

-Call Waiting: Works perfectly, as do unanswered Call-Waiting
redirects.

-Three-Way: Again, works perfectly- it is more "elegant" to the roamer
on the Ericsson than it is back at home on the Motorola!

Bugs:

1. As noted before, the "xx-44" codes seem to be in error. Perhaps
they are using the 1+ mechanism to determine if a redirect should
occur or not and if not for some reason the switch coughs up the 44
recording?

2. If a visiting roamer has no conditional forwarding (NAT, BT) set,
the call will ring in the visited market for an exceptionally long
period of time (over 1 minute!), which is unusual and wastes airtime
and handheld battery power. After about a minute or longer, the
calling party does not get a recording, but rather a fast busy.

3. Sort of a bug: CO/Boston customers must (unfairly, IMHO) pay
AIRTIME for call delivery, even though it is obvious to anyone that no
airtime is being used if the subscriber isn't even in Boston system.
(And the old excuse that "oh, you utilize a lot of trunk lines with
call delivery" is nonsense -- the visiting system's roaming charges
are
enough to discourage flagrant overuse of CO/Boston's trunks).
CO/Boston always used to maintain that customers could avoid these
charges by having callers reach them by using the local roam ports.

However, traditionally, when a system is added to the NACN, its
customers are no longer accessible via the roam ports of another NACN
member's system, and thus, if the same holds true for Boston, there is
now NO WAY to receive calls without paying home airtime in Boston.

Since the entire idea behind the NACN is nearly seamless service, it
would be in SWBell's best interests to rid itself of this inane
money-grabbing policy. However, if they are too stingy to let it go,
then the roam ports need to be "open" for Boston subscribers who wish
to avoid these charges.

Overall, however, a very nice and smooth addition to the NACN, with
only a few minor problems to resolve.


Doug Reuben              [e-mail]              (203) 499 -
5221
Interpage Network Services -- E-Mail/Telnet to Alpha or Numeric Pagers
& Fax

------------------------------

From: [e-mail]
Subject: Canadian CIC Codes
Date: Wed, 18 Jan 1995 21:26:54 GMT
Organization: CSRNet(Voice 1705-949-9275 Data 1705-942-5370)


To Pat and all those looking for the Canadian 10XXX codes, here is the
latest list I have, issued by Industry Canada (formerly Dept. of
Communications), and the address to write to for updates:

Stentor says that responsibility for 10xxx and 950-xxxx numbers has
been trasnferred from Stentor to Industry Canada, effective March 1,
1994. The new address for the Canadian Nmmbering Administrator (CNA)
is:

  Christiane Chasle
  Canadian Numbering Administrator (CNA)
  Industry Canada
  300 Slater Street, 18th Floor
  Ottawa, Ontario
  K1A 0C8
  Telephone [phone]

Stentor also sent me a list of the codes, as they were before
responsibility for numbering was assigned to Industry Canada.  CIC
stands for Carrier Identification Code, I think.

The table is confusing. A code of 869 identified as 3D FG B&D is a
three digit code used for both Feature Group B (950-xxxx) and Feature
Group D (10xxx), so it would expand to 950-0869 and 10869. A CIC
identified as 4D FGB expands to 950 followed by the four digits.

 Assigned Carrier       CIC Code        Feature Group
 Unitel                 869*            3D FG B&D
    *869 is U.S. CIC
 Unitel                 686             3D FG B&D
 Unitel                 858             3D FG B&D
 AGT                    424             3D FGD
 BC Tel                 323             3D FGD
 Bell Ontario           363             3D FGD
 Bell Quebec            484 (see note)  3D FGD
 Note: Bell Quebec CIC reclaimed 1993-11
 Island Tel, PEI        422             3D FGD
 Manitoba Tel System    783             3D FGD
 Maritime Tel & Tel     434             3D FGD
 NB Tel                 448             3D FGD
 Newfoundland Tel       445             3D FGD
 Sask Tel               242             3D FGD
 EdTel                  324             3D FGD
 Sprint Canada          5348            4D FGB
 Sprint Canada          348             3D FGD
 ACC                    1234            4D FGB
 ACC                    234             3D FGB
 Fonorola               507             3D FGD
 Fonorola               5507            4D FGB
 Westel                 5978            4D FGB
 Westel                 978             3D FGD
 STN                    773             3D FGD
 ATCI                   235             3D FGD
 TelRoute               318             3D FGD

I assume that Bell Quebec will be using the Bell Ontario code of 363.
After all, both Bell Quebec and Bell Ontario are simply divisions of
Bell Canada, not separate corporations.

A more up-to-date list of these codes may be available from Industry
Canada, at the above address.

Note: Not all carriers accept casual calling, and not all carriers are
available from each province.


Chris
  The Collosus Soo Resource Network - CSRNet - Gated InterNet
Newsgroups
       40,000 + Files Online - 6 Lines - 1-705-942-5370 (16.8 USR DS)
            File Request CSRNET or FILES from 1:222/21 or 11:11/0
  Satellite Downlink - 5-10 Megs of New Files Daily 1-705-949-7224
(28.8)

------------------------------

From: [e-mail] (Peter Granic)
Subject: Questions About WAN Compression For Data Networks
Date: 19 Jan 1995 08:09:29 -0500
Organization: Internex Online (io.org) Data: 416-363-4151  Voice: 416-
363-8676


I would appreciate it if someone could fill me in on how WAN
compression is developing as they see it.  Currently, we are only
using V.FAST Motorolla modems with synchronous data compression in
order to get throughputs of up to 30Kbs on a data-conditioned phone
line.  I was more interested in the use of compression in order to
improve leased line performance, and thus leased line costs.  By the
way, the V.Fast modems are used to give us some decent bandwidth to
"hick town" sites, where we can't get centrex or ISDN.

Now regarding compression on regular leased circuits:

As far as I can tell, the option is a no-brainer.  Most companies
advertise compression of 2.5-4 times, so that say 56K circuits can
give an effective bandwidth of 130-200Kbs.  So, for example, Cisco is
advertising that they will be bundling this capability with their
routers in order to help reduce customer's costs.

Question: Is most of the compression which bridge and router
manufactures use for WAN access implemented in software or hardware?

Question: Is most of this technology developed in-house using standard
compression algorithms?  Do they license compression
algorithms/technologies from other companies?

Question: Assuming compression is being done with a third party
vendor, i.e.  hypothetically, let's say a Wellfleet router is used in
combination with say some Motorolla equipment (I imagine they have it
for leased lines) to increase WAN bandwidth. Is adding the extra
vendor a major headache in terms of operating the network, as opposed
to bundling the components into one vendor's products?


Thanks,

Peter Granic

------------------------------

Date: Thu, 19 Jan 1995 09:41:21 +0000
From: [e-mail]
Subject: Re: DQDB AND SMDS


Greetings, Fred.

>> Can anybody explain to me what the difference and/or connection is
>> between DQDB (Distributed-Queue dual-bus) and SMDS (Switched
>> Multi-Megabit Data Service).

> Interesting topic, since the two are easily confused.

> DQDB is a "Metropolitan Area Network" defined by IEEE 802.6.  It
> provides for a cell-based (48-byte payload, similar to ATM) data
> transfer, shared media with arbitration (telco speeds, T1/E1/T3/E3/
> SONET/SDH as intended PMDs), and a novel combination of MAC
services.

Right!

(BTW: How many bit/s are T1/E1/T3/E3. etc.?)

> SMDS is a connectionless packet-switched public network service
> developed by Bellcore.  It uses E.164 (ISDN/telephone numbers) for
> addresses, allows long (9KB?) packets, etc.

Sounds a lot like a OSI-variant of the IP Internet. (?)

> When SMDS was being invented, DQDB was hot, so Bellcore specified
that
> the data link layer of SMDS would be the DQDB protocol.  This is
"SIP
> layer 2" and part of "SIP layer 3".  Thus it is possible to
implement
> SMDS using DQDB multiport bridges.  This is done in some places.  In
> effect, SMDS is a service that DQDB delivers using a subset of its
> capabilities.

Seames to be the situation here in Belgium.

> In American practice, most users do not accept DQDB's odd cell-based
> datalink, so SMDS now usually uses the "DXI" format, which maps SIP3
> packets into HDLC frames.  Some DQDB vestiges (packet header,
trailer)
> remain but it's really just a packet service now.

I am more interested in the situation in Europe.

Anybody any info on MAN networks in Europe. (As far as I know, there
is -at least- a MAN in stockholm and one somewhere in the UK).


·
Technology? Number of users? Pricing? Interconnection?

Talking of interconnection: I've read some the 'grand plan' is to
build a number of high-speeds interconnection pockets (mainly using
DQDB, ...) and the interconnect them all using ATM-links.

Are there already such interconnections? Does there exists an
international numbering-sceme for all these networks?

For the record, this is the situation in Belgium:

BelgaCom (up to 1998 Belgium's sole operator) operates a MAN in two
cities: Brussels and Antwerp.  They use DQDB and operate at 140 Mbit/s
internally. The MANs are interconnected at 34 Mbit/s.  Connections to
the MAN are possible at speeds of 2 and 34 Mbit/s, using 802.3
ethernet, 802.5 token ring, 802.6 DQDB and G.703. (whatever that may
be ;-)) SMDS is supported.

Apart from that, there is a ATM-based network in the province of
Antwerp (called 'MANAP'), operated by the {city|province} of Antwerp.

Brussels also houses a switch of the (well known) pan-European ATM
pilot network. (of which I have no further information neither ;-)).


Cheerio!

Kristoff Bonne, BelgaCom IS/TeLaNet           netwerk planning en -
beheer
(C=BE;A=RTT;P=RTTIPC;S=Bonne;G=Kristoff)      fax         :  +32 2
2025497
[e-mail]             Voice mail  :  +32 70
615492

------------------------------

From: [e-mail] (David O. Laney)
Subject: ANSI Terminal Communications
Date: Thu, 19 Jan 1995 13:12:32 GMT
Organization: Free-Net Erlangen Nuernberg, Germany


Hi Netters,

I am interested in getting the ANSI Terminal Standards (i.e. escape
sequences) to use to drive a communications package. I would like to
get the full set of sequences of which ansi.sys in the DOS world is
only a subset of.  If you know how to get a hold of the standards or
Ansi people. Please drop me a line at [e-mail].

Thanking you in advace.


From: David O. Laney         Internet: [e-mail]
Voice: [phone]     Fax: [phone]

------------------------------

From: L.C. Clower <[e-mail]>
Subject: Internet Software Wanted
Date: Thu, 19 Jan 95 02:09:29 -0500
Organization: Delphi ([e-mail] email, 800-695-4005 voice)


Somebody please drop me an email re: software packages to access
Internet. I have local access to Sprintnet but what do I need now?

Have PC.


Thanks,

L. C. Clower [e-mail]

------------------------------

From: [e-mail] (Mark Fraser)
Subject: Re: T1BBS Gone?
Date: 19 Jan 1995 07:32:22 GMT
Organization: Wimsey Information Services


I've answered my own question.  ftp ftp.t1.org ; telnet t1bbs.t1.org.
New phone numbers in Washington, DC. The site moved from California.
That explains why my problem.

------------------------------

From: [e-mail] (Mark Fraser)
Subject: Re: BC Tel, SaskTel, Internet
Date: 19 Jan 1995 07:39:22 GMT
Organization: Wimsey Information Services


I shouldn't be so irreverent, but I interpret BCTel's response to mean
"Someone already has control of the urban centers at 1.60 an hour,
we're getting 9.00 or more an hour from the smaller places now, why
should we reduce it to the three bucks or so that Sask is charging
 ..."  I bet they don't say THAT when you call.  Earlier information
 -- New Brunswick.  NBTel went from free to 10.00 an hour last year,
so everyone went away.  Last I heard, only a few came back when they
reduced it back to five bucks.

And then we have Brent Sauder of the Advanced Systems Institute
[sorry, Brent ....] who was also quoted in the Sun as rejecting the
concept of "put it in place and they will find a use for it".  Set the
movement back ten years.  And the telcos are telling us that Rogers
and
Shaw are arrogant.

Time for the revolt, folks ...


/Mark

------------------------------

From: Liron Lightwood <[e-mail]>
Subject: Re: Wireless CO's Challenge New NPAs?
Date: Thu, 19 Jan 1995 19:12:20 +1100


Regarding the question of people always having to dial an area code if
cellular phone numbers were moved to their own prefix.  This does not
have to be the case.

Here in Australia, we have the best of both worlds.  Our cellular
phones have their own area code like prefixes, e.g. 018, 015, 041.
However, when making a local call from a cellular phone, you only have
to dial the six or seven digit number, no area code required.

For example, if you're in Melbourne (03), to dial [phone], you
would dial 123 4567.  If you were in Sydney (02) and you wanted to
dial [phone] you would dial 123 4567.

To dial another cellular phone from a cellular phone, you would have
to dial the whole number, including the prefix.

Perhaps this sort of system could be implemented in the US, thus
solving the problems which the wireless CO's are concerned about.

The only problem is areacode splits.  Suppose you were near the
213/310 boundary.  How would the cellular phone base station know
which side you were on?  What about the customer?


Liron (Ronny) Lightwood - [e-mail]   <=== NEW ADDRESS
                   Insane Public Access, Melbourne Australia


[TELECOM Digest Editor's Note: Unless I am misunderstanding something,
we do dial calls now as you suggest. If a cellular phone is in area
708
(that is, *based* in 708, or using that as its 'home') then we need to
merely dial the seven digit number. It does not matter where the phone
actually happens to be in at the moment; the phone could be in New
York
for all anyone cares. If 'follow me roaming' is turned on, we still
just
dial the seven digits if in the same 'area'.    PAT]

------------------------------

From: [e-mail] (Colum Mylod)
Subject: Re: Attention: 800 Number Subscribers (News Alert)
Date: 19 Jan 1995 09:05:01 GMT
Organization: Oracle Corporation. Redwood Shores, CA
Reply-To: [e-mail]


[e-mail] wrote:

> Why would any European customer wish numbers like 800 THE CARD,
unless
> they expect most of their traffic from the US?  [...]
> In Europe letters are *not* used.  And when they were used
assignment
> was not identical to the US assignment.  See the telecom archives
for
> an article were I gave some European assignments.

Ah but Dik, British Telecom intends to reintroduce letters in phone
numbers (they've been on various phone units for a long while --
imports mainly).  Even in non-English Europe you'll see them back if
for no other reason than introducing variety in freephone numbers.
Currently a lot of European (monopoly) telcos issue patterned numbers
like <code> 123456 or 876 876 etc. Having letters ups the 'saleable"
freephone number combinations.

According to a brief glimpse I got at uk.telecom (is this available
via listserv anyone?), BT will use the same letters-numbers pattern as
the Bell one but with Z added to the 9 key and Q on 0 (I think, going
from memory). The original British pattern had letter-O on number-0
(THAT's sensible IMHO).

------------------------------

From: [e-mail] (Ben Wright)
Subject: Re: GSM Cellular Operators List
Date: 19 Jan 1995 12:16:42 GMT
Organization: Microplex Pty Ltd


Australia has three GSM networks, Telecom, Optus and Vodafone.

------------------------------

From: [e-mail] (Andreas Junklewitz)
Subject: Summary: Looking For a CHILL Compiler
Date: 19 Jan 1995 13:44:14 GMT
Organization: RWTH Aachen
Reply-To: [e-mail]


The solution for my problem seems to by the pre-release of the GNU
Chill compiler. It is available by anonymous ftp at ftp.cygnus.com:
pub/chill-1.4.tar.gz.

Thank you very much for your answers:

         Per Bothner <[e-mail]>
         Mike Stump  <[e-mail]>


With best regards,

Andreas Junklewitz, Phone: ++49-241-806984, Telefax: ++49-241-8888186
Institute for Communication Systems and Data Processing
RWTH-Aachen (University of Technology)
Muffeter Weg 3, 52072 Aachen, Germany
E-Mail: [e-mail]        or      junklewitz@rwth-
aachen.de

------------------------------

Date: Wed, 18 Jan 95 23:05:51 GMT
From: Carl Moore <[e-mail]>
Subject: Re: NANP 800 Numbers From the UK


Drat, I forgot to ask (or notice?) what happens when you dial that
North American 800-MY-ANI-IS from the UK.


[TELECOM Digest Editor's Note: Two or three people reporting on this
said
MY-ANI-IS reported they were calling from something like 702-000-5555.
Someone else mentioned their belief that calls from Europe to 800
numbers
are being sent to somewhere in Nevada where they are then in turn
being
sent out to the actual numbers, thus the 702 part of the ANI.   PAT]

------------------------------

Subject: Re: Legal Problem Due to Modified Radio
From: drharry![e-mail] (Alan Boritz)
Date: Thu, 19 Jan 95 07:42:46 EST
Organization: Harry's Place - Mahwah NJ - [phone]


[e-mail] (Bill Garfield) writes:

> While the writer is correct in his statement that Amateur or Ham
radio
> equipment is not 'type-accepted', equipment which -lawfully-
operates
> on commercial frequencies (police frequencies) and is capable of
> TRANSMITTING thereon, _must be_ type accepted, approved and
certified
> for such use.  The modifications therefore would constitute an
equipment
> technical violation.

No, Bill, they wouldn't.  The transmitter wasn't operated on those
frequencies, therefore there was no "technical violation."

> Although the act of 'tampering' with non type-accepted equipment is
> allowable, the moment that equipment radiates energy on frequencies
> where type acceptance _is_ a requirement, then the modified
equipment
> is in violation and as "property" it becomes contraband.

But the equipment described wasn't operated on non-amateur
frequencies,
therefore it was never "in violation."

> While FCC regulations deal mainly with use and not possession, the
> writer may still be on shaky ground.  I certainly wouldn't want the
> local constabulary _aware_ that I possessed transmitting equipment
> capable of operating on their lawfully assigned frequencies.

Not shaky by any means, just not wise. <g>

> But the obvious question which remains unanswered is -why- was the
> person's room searched in the first place?  "Reasonable suspicion"
is
> sufficient grounds in most jurisdictions, but suspicion of what?

Suspicion of ACTUALLY causing harmful interference doesn't seem to be
an issue, since it doesn't seem to have been raised.  It would appear
that the sole purpose of confiscating the radio was because it MIGHT
be used to transmit on local government frequencies.  There's a big
difference between MIGHT and DID.

> [TELECOM Digest Editor's Note: Well, this is something the original
> writer did not explain to us, and as you suggest, it seems like a
very
> important part of this whole mystery. If their 'reasonable
suspicion'
> had to do with improper or inappropriate transmissions on the radio,
> then the defenses discussed to date may go topsy-turvy in court.

Not exactly.  I would expect that it would be just the opposite.  If
the
officers were looking for a pirate transmitter that *caused* (in the
past
tense) interference with their communications, they were CLEARLY
outside of
their jurisdiction.

------------------------------

End of TELECOM Digest V15 #47
*****************************